feat: Optional Storage health check#73
Conversation
…ew run commands and other general formatting improvements; add optional health check for storage on startup
rpatel-figure
left a comment
rpatel-figure
left a comment
There was a problem hiding this comment.
If I run cargo --config .cargo/fs.config.toml, does it merge .cargo/config.toml in as well? Not clear to me from the docs.
| /// One of: `file_system`, `google_cloud` | ||
| pub storage_type: String, |
There was a problem hiding this comment.
Should from_env verify this, for convenience?
There was a problem hiding this comment.
I'll just make it an enum
Yes, from below:
|
I guess my question is if |
Ah, from running locally, I can answer yes. I think coupled with "Cargo allows local configuration for a particular package as well as global configuration. It looks for configuration files in the current directory and all parent directories. If, for example, Cargo were invoked in /projects/foo/bar/baz, then the following configuration files would be probed for and unified in this order:" that I read that it always uses it, but it does read slightly ambiguous |
2 participants
Context
There is no way to verify storage backend is accessible on startup, which can make it hard to debug infrastructure configuration runtime errors. Also, the custom shell script (bin/env) for setting environment variables during local development is a non-standard approach and doesn't integrate well with Cargo's tooling.
Changes
env: Replaced custombin/envscript with standard Cargo configuration using.cargo/config.tomlwith separate config files for storage backends:.cargo/fs.config.toml(file system) and.cargo/google_cloud.config.toml(Google Cloud)StorageConfiginto its own struct for better organizationStoragetrait, runs ifSTORAGE_HEALTH_CHECK=truedefaults to false for backwards compatibilityca-certificatesto docker image to resolve cert issue with google cloud